Network Working Group K. Zeilenga 
Request for Comments: 4527 OpenLDAP Foundation 
Category: Standards Track June 2006 


Lightweight Directory Access Protocol (LDAP) 
Read Entry Controls 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 

Abstract 
This document specifies an extension to the Lightweight Directory 
Access Protocol (LDAP) to allow the client to read the target entry 
of an update operation. The client may request to read the entry 
before and/or after the modifications are applied. These reads are 


done as an atomic part of the update operation. 


Table of Contents 


i. -Baekground -and-IntéentOFf Use gans u ok dead Be i ets Bole bate BO Slee 2 
25 VELMINGLO GY! snark Wid) S corer a Bod ma a eld ew Slee a elas conga a LOU ager a Wl ae ones 2 
3s Read Entry CONE COUS: «iii ce ees ee catalan ieee eared 9s gen ean eater eee erecta aig abies ogee 3 
34: The Pre+Read. Controls: 2.5% 33 he's gw ots 8 CAs ee O Swe EPO ees 3 
3026 “TRE Post-—R6ad Control's os eis Be Mats eels Bis te Soe we Nite ae eS 3 
4%. Interaction’ with Other COntrols: gee ases eds a a a How N BE 4 
5; Security- Consideratións sesa sse ea ae oe a a oie Sh eases a a a S 4 
6s ALANA. GCGönsriderat TONS saaara e onea eS Be Se a a OWS eS ORE a a aS 5 
Cid SOD SCE, As STi ITIC io e a E a E a e E Mar a E whol E ana s 5 
6.92, “LDAP Protocol Mechanisms sess eras iei ea ae Silo a OA a E a ea gS 5 
Tar AEkNowLledgement fea cede ec a estes le cai ld Ge od ete eS Gear Se us cols Gee eee a ss Ge we er es 5 
8s, RETSrEnCEST ie rante n aa a Ge a See a aaa Bish we Biles SNe a a BAS @ SOS Soe 6 
8413 Normative RETerenCes: en. ccs So eA Oe 4 See Sly Seek Saree ewes 6 
8.2. “Informative: References aese eera a e beh ge Sele e a Eb ae See 7 


Zeilenga Standards Track [Page 1] 


RFC 4527 LDAP Read Entry Controls June 2006 


Le 


Background and Intent of Use 


This document specifies an extension to the Lightweight Directory 
Access Protocol (LDAP) [RFC4510] to allow the client to read the 
target entry of an update operation (e.g., Add, Delete, Modify, 
ModifyDN). The extension utilizes controls [RFC4511] attached to 
update requests to request and return copies of the target entry. 
One request control, called the Pre-Read request control, indicates 
that a copy of the entry before application of update is to be 
returned. Another control, called the Post-Read request control, 
indicates that a copy of the entry after application of the update is 
to be returned. Each request control has a corresponding response 
control used to return the entry. 


To ensure proper isolation, the controls are processed as an atomic 
part of the update operation. 


The functionality offered by these controls is based upon similar 
functionality in the X.500 Directory Access Protocol (DAP) [X.511]. 


The Pre-Read controls may be used to obtain replaced or deleted 
values of modified attributes or a copy of the entry being deleted. 


The Post-Read controls may be used to obtain values of operational 
attributes, such as the ’entryUUID’ [RFC4530] and ’modifyTimestamp’ 
[RFC4512] attributes, updated by the server as part of the update 
operation. 


Terminology 


Protocol elements are described using ASN.1 [X.680] with implicit 
tags. The term "BER-encoded" means the element is to be encoded 
using the Basic Encoding Rules [X.690] under the restrictions 
detailed in Section 5.1 of [RFC4511]. 


DN stands for Distinguished Name. 
DSA stands for Directory System Agent (i.e., a directory server). 
DSE stands for DSA-specific Entry. 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in BCP 14 
[RFC2119]. 
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Read Entry Controls 
1. The Pre-Read Controls 


The Pre-Read request and response controls are identified by the 
1.3.6.1.1.13.1 object identifier. Servers implementing these 
controls SHOULD publish 1.3.6.1.1.13.1 as a value of the 
‘supportedControl’ [RFC4512] in their root DSE. 


The Pre-Read request control is a LDAP Control [RFC4511] whose 
controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded 
AttributeSelection [RFC4511], as extended by [RFC3673]. The 
criticality may be TRUE or FALSE. This control is appropriate for 
the modifyRequest, delRequest, and modDNRequest LDAP messages. 


The corresponding response control is a LDAP Control whose 
controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET 
STRING, contains a BER-encoded SearchResultEntry. The criticality 
may be TRUE or FALSE. This control is appropriate for the 
modifyResponse, delResponse, and modDNResponse LDAP messages with a 
resultCode of success (0). 


When the request control is attached to an appropriate update LDAP 
request, the control requests the return of a copy of the target 
entry prior to the application of the update. The AttributeSelection 
indicates, as discussed in [RFC4511] [RFC3673], which attributes are 
requested to appear in the copy. The server is to return a 
SearchResultEntry containing, subject to access controls and other 
constraints, values of the requested attributes. 


The normal processing of the update operation and the processing of 
this control MUST be performed as one atomic action isolated from 
other update operations. 


If the update operation fails (in either normal or control 
processing), no Pre-Read response control is provided. 


.2. The Post-Read Controls 


The Post-Read request and response controls are identified by the 
1.3.6.1.1.13.2 object identifier. Servers implementing these 
controls SHOULD publish 1.3.6.1.1.13.2 as a value of the 
‘supportedControl’ [RFC4512] in their root DSE. 


The Post-Read request control is a LDAP Control [RFC4511] whose 
controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET 
STRING, contains a BER-encoded AttributeSelection [RFC4511], as 
extended by [RFC3673]. The criticality may be TRUE or FALSE. This 
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control is appropriate for the addRequest, modifyRequest, and 
modDNRequest LDAP messages. 


The corresponding response control is a LDAP Control whose 
controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded 
SearchResultEntry. The criticality may be TRUE or FALSE. This 
control is appropriate for the addResponse, modifyResponse, and 
modDNResponse LDAP messages with a resultCode of success (0). 


When the request control is attached to an appropriate update LDAP 
request, the control requests the return of a copy of the target 
entry after the application of the update. The AttributeSelection 
indicates, as discussed in [RFC4511] [RFC3673], which attributes are 
requested to appear in the copy. The server is to return a 
SearchResultEntry containing, subject to access controls and other 
constraints, values of the requested attributes. 


The normal processing of the update operation and the processing of 
this control MUST be performed as one atomic action isolated from 
other update operations. 


If the update operation fails (in either normal or control 
processing), no Post-Read response control is provided. 


4. Interaction with Other Controls 


The Pre-Read and Post-—Read controls may be combined with each other 
and/or with a variety of other controls. When combined with the 
assertion control [RFC4528] and/or the manageDsaIT control [RFC3296], 
the semantics of each control included in the combination applies. 
The Pre-Read and Post-—Read controls may be combined with other 
controls as detailed in other technical specifications. 


5. Security Considerations 


The controls defined in this document extend update operations to 
support read capabilities. Servers MUST ensure that the client is 
authorized for reading of the information provided in this control 
and that the client is authorized to perform the requested directory 
update. 


Security considerations for the update operations [RFC4511] extended 
by this control, as well as general LDAP security considerations 
[RFC4510], generally apply to implementation and use of this 
extension 
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Registration of the following protocol values 
completed by the IANA. 


IANA Considerations 


Object Identifier 


Subject: Request for LDAP Object Identifier Registration 


Person & email address to contact for further information: 


Kurt Zeilenga <kurt@OpenLDAP.org> 
Specification: RFC 4527 
Author/Change Controller: IESG 
Comments: Identifies the LDAP Read Entry Controls 


LDAP Protocol Mechanisms 


The IANA has registered the LDAP Protocol Mechanism described 
document. 


Subject: Request for LDAP Protocol Mechanism Registration 
Object Identifier: 1.3.6.1.1.13.1 
Description: LDAP Pre-read Control 


[RFC4520] have been 


The IANA has registered an LDAP Object Identifier to identify LDAP 
protocol elements defined in this document. 


in this 


Person & email address to contact for further information: 


Kurt Zeilenga <kurt@openldap.org> 
Usage: Control 
Specification: RFC 4527 
Author/Change Controller: IESG 
Comments: none 


Subject: Request for LDAP Protocol Mechanism Registration 
Object Identifier: 1.3.6.1.1.13.2 
Description: LDAP Post-read Control 


Person & email address to contact for further information: 


Kurt Zeilenga <kurt@openldap.org> 
Usage: Control 
Specification: RFC 4527 
Author/Change Controller: IESG 
Comments: none 


Acknowledgement 
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The LDAP Pre-Read and Post-Read controls are modeled after similar 
capabilities offered in the DAP [X.511]. 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 
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